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1 Scope 

The present document provides the possible scenarios for: 

• the interconnection of an Next Generation Corporate Network (NGCN) with a Next Generation 
Network (NGN); and 

• the support of NGCN capabihties within an NGN, either towards a User Equipment (UE) or to an NGCN. 

Unless otherwise specified by reference to other documents, all requirements relating to architecture and functional 
requirements are contained within the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 182 009: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Architecture to support emergency communication from 
citizen to authority". 

[2] ETSI TS 181 019: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Business Communication Requirements". 

[3] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture". 

[4] ETSI TS 182 024: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Hosted Enterprise Services; Architecture, functional description 
and signalling". 

[5] ETSI TS 182 025: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Business trunking; Architecture and functional description". 

[6] ETSI TS 183 021: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Endorsement of 3GPP TS 29.162 Interworking between 
IM CN Sub-system and IP networks". 
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[7] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Security Architecture". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 102 478: "Enterprise Communication in Next Generation Corporate Networks (NGCN) 

involving Public Next Generation Networks (NGN)" (also published as ECMA TR/91). 

[i.2] draft-ietf-sipping-sbc-funcs-05 (March 2008): "Requirements from SIP (Session Initiation 

Protocol) Session Border Control Deployments". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purpose of the present document, the terms and definitions given in TS 181 019 [2] apply: 

business trunking 

business trunking application 

Corporate telecommunication Network (CN) 

Hosted Enterprise Services (HES) 

Next Generation CN (NGCN) 

NGCN site 

PNP number 

private network traffic 

Private Numbering Plan (PNP) 

public network traffic 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

API Application Programming Interface 

AS Application Server 

ASP Application Service Provider 

BGCF Breakout Gateway Control Function 

CN Core Netwrok 

CND Customer Network Device 

CNG Customer Network Gateway 

DHCP Dynamic Host Configuration Protocol 

FQDN Fully Qualified Domain Name 

HES Hosted Enterprise Services 

HSS Home Subscriber Server 

IBCF Interconnection Border Control Function 

I-CSCF Interrogating CSCF 

IM IP Multimedia 

IMCN IP Multimedia Core Network 

IMS IP Multimedia Subsystem 

lOI Inter Operator Identifier 

IP Internet Protocol 

IWF InterWorking Function 

MACE Multiple Association Control Function 

NASS Network Attachment Subsystem 

NAT Network Address Translator 
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NGCN Next Generation Corporate Network 

NGN Next Generation Network 

P-CSCF Proxy CSCF 

FN? Private Numbering Plan 

PSAP Public Safety Answering Point 

RACS Resource and Admission Control Subsystem 

S-CSCF Serving CSCF 

SIP Session Initiation Protocol 

SSP Session Service Provider 

TE Terminal Equipment 

TSP Transport Service Provider 

UE User Equipment 

UPSF User Profile Service Function 

URI Uniform Resource Identifier 



4 Introduction 

4.1 General modelling and relationship to NGN releases 

A number of different scenarios will likely exist for enabling interactions between Next-Generation Corporate 
Networks (NGCN) and Next Generation (public) Networks (NGN). The present document describes a sub-set of these 
scenarios and the architectural and functional requirements that arise from the support of these scenarios. Future 
releases may document other scenarios as requirements emerge. 



4.2 Levels of service provision 



The development of different interaction scenarios based upon the distribution of the hosting of private network 
capabilities in the enterprise operator and/or in the public NGN operator leads to the concept of the public NGN 
operator being able to offer services to NGCNs and the NGCN users at a number of different levels. This concept is 
further described in TR 102 478 [i. 1]. 

The most basic level of service provision is IP connectivity. Differentiation from the Internet can be in the form of 
improved or guaranteed quality of service or security. For the purposes of the present document an NGN that provides 
this level of service acts as a Transport Service Provider (TSP). 

A second level of service provision is in session establishment and control of communication sessions, e.g. voice, 
multimedia, messaging. Here the NGN adds value by being involved in the signalling protocol used to establish and 
control media sessions. For the purposes of the present document the primary session control signalling protocol 
concerned is assumed to be the Session Initiation Protocol (SIP). Added value can include intelligent routing, provision 
of quality of service for media, provision of gateway services to legacy networks, assistance in NAT traversal, etc. For 
the purposes of the present document an NGN that provides this level of service is known as a Session Service Provider 
(SSP). 

A third level of service provision is at the application level. Applications can be many and varied, but for the purposes 
of the present document an application is assumed to be applied on top of session level services. An application may be 
able to monitor or control multi-media sessions (either directly or through a protocol or API) and may or may not be 
involved in media as well. Examples of applications that involve media include conferencing services, transcoding and 
translation services and call distribution centres. Examples of applications that monitor or control sessions but do not 
involve media include presence services, call logging services and UA configuration services. In addition, an 
application may be accessed through a session control protocol such as SIP. For the purposes of the present document 
an NGN that provides this level of service is known as an Application Service Provider (ASP). 

NOTE 1 : An NGN acting as an ASP is not necessarily providing these capabilities on an IMS application server, it 
is providing any level of functionality above that of an SSP at any appropriate entity. 
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An NGN may provide services at one or more of these levels. Not all services offered will be of interest to enterprise 
customers and of relevance for interworking with NGCNs. Enterprise customers may use different NGNs for different 
levels of service provision and may have different contractual relationships with each of these NGNs. In addition, for a 
given communication and depending on the number of parties to be interconnected and/or the number of services to be 
accessed, multiple providers may be involved. 

NOTE 2: Similarly an NGCN can provide services at these three levels to enterprise users. In particular, services at 
the session establishment and control level and/or application level can be provided by an NGCN site to 
enterprise users on other NGCN sites or supported by hosted enterprise services. 

The scenarios provided in the present document are presented in accordance with this concept. 

4.3 Introduction to the scenarios covered by the present 
document 

The present document has been structured following the service level categories as introduced in clause 4.2 in mind, as 
follows: 

• clause 6 presents scenarios that relate to provision of IP connectivity level services offered by an NGN; 

• clause 7 presents scenarios that relate to provision of session establishment and control of communication 
session services offered by an NGN; 

• clause 8 presents scenarios that relate to provision of application level services offered by an NGN; and 

• clause 9 presents scenarios that relate to provision of session level roaming services offered by an NGN. 

The scenarios presented in Clause 6 are IP level virtual leased line services between NGCN sites or between an NGCN 
site and a remote NGCN UE. 

The scenario presented in clause 7 is a session level virtual leased line. 

The application level service scenarios presented in clause 8 are hosted enterprise services (HES), subscription based 
business trunking and peering based business trunking. 

Clause 9 presents a special class of session level service scenarios that are so distinct from other session level services 
that they are a service class of their own. Roaming scenario covered in this release is the ability for an NGCN user to be 
able to roam into an NGN with which the NGCN has a roaming agreement. Other scenarios are listed for completeness, 
however these scenarios are not in the scope of the current release or are already covered as part of normal roaming 
procedures. 



5 General requirements 

No additional general requirements are identified in the present document for this release. 

6 Scenarios relating to a level of service of IP 
connectivity 

6.1 Scenario 1 : IP VPN providing a virtual leased line between 
NGCN sites 

6.1.1 Introduction 

This scenario describes the provision of capabilities of the NGN to provide a IP VPN providing a virtual leased line 
between two NGCN sites. The NGN provides no other functionality. 
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6.1 .2 Involved functional entities - originating 

Figure 6.1.1 shows the functional entities involved in the originating scenario in support of IP VPN interconnection. 

Mandatory for scenario 



Optional for scenario 
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Figure 6.1.1 : Originating scenario for IP VPN interconnection 

6.1 .3 Involved functional entities - terminating 

Figure 6.1.1 shows the functional entities involved in the terminating scenario in support of IP VPN interconnection. 
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Figure 6.1.2: Terminating scenario for IP VPN interconnection 

6.1 .4 Interoperability with other scenarios 

Clauses 6.1.2 and 6.1.3 can be combined together to provide an NGN transit scenario. 

Clause 6.1.2 is also intended to interoperate with clause 6.2.3, and clause 6.1.3 to interoperate with clause 6.2.2, in order 
to allow similar functionality allowing a remote terminal to access an NGCN site. 

Interoperability with other business communication scenarios is not possible. 

NOTE: Interconnection with other scenarios is not possible, because there is no IP VPN termination in the NGN 
to support interworking the IP VPN. 

6.1.5 Emergency calls 

In this scenario, emergency calls have to be supported entirely within the NGCN, and some other scenario provided for 
delivery to the NGN if required. 
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6.1 .6 Configuration / provisioning issues 

The IP level communication between the two NGCNs can be provided using a number of mechanisms. The simplest 
mechanism is to configure peer IP addresses or FQDNs, and appropriate credentials for the security mechanism in use, 
in the IP VPN termination. The configuration of this information is outside the scope of the present document. 

There are no configuration requirements for supporting this scenario in the NGN. 

6.1.7 Security issues 

Security is provided by appropriate security mechanism between the IP VPN endpoints, e.g. IPsec or TLS. Whether the 
NGN provides security mechanisms depends on the service level agreements. 

6.1.8 CInarging issues 

Not applicable. 

6.1 .9 Transport control issues 

The NGCN site interfaces to the NGN using an IP VPN termination and the CNG which can both be an integral part of 
the NGCN equipment. 

NASS can be used, e.g. to support the allocation of a IP address to the CNG, and the authentication of the CNG as an 
endpoint. 

RACS can be used by the NGN to control enforcement of policies within the transport layer. These policies are pushed 
to the RACS by the NASS each time the CNG attaches to the NGN. 

NOTE: The RACS could have similar functionality to the above based on receipt of the policies from the 
management plane. 

6.2 Scenario 2: IP VPN tunnel providing a virtual leased line 
between a remote terminal and an NGCN sites 

6.2.1 Introduction 

This scenario describes the provision of capabilities of the NGN to provide a IP VPN tunnel providing a virtual leased 
line between a remote terminal and an NGCN site. The NGN provides no other functionality. 

6.2.2 Involved functional entities - originating 

Figure 6.2.1 shows the functional entities involved in the originating scenario in support of IP VPN interconnection. 
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Mandatory for scenario 



Optional for scenario 
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Figure 6.2.1 : Originating scenario for IP VPN interconnection 

6.2.3 Involved functional entities - terminating 

Figure 6.2.2 shows the functional entities involved in the terminating scenario in support of IP VPN interconnection. 
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Figure 6.2.2: Terminating scenario for IP VPN interconnection 



6.2.4 Interoperability with other scenarios 

Clauses 6.2.2 and 6.2.3 can be used in conjunction with the IP VPN tunnel providing a virtual leased line to an NGCN 
to provide interoperability. Thus clause 6.1.2 is also intended to interoperate with clause 6.2.3, and clause 6.1.3 to 
interoperate with clause 6.2.2. 

Interoperability with other business communication scenarios is not possible. 

NOTE: Interconnection with other scenarios is not possible, because there is no IPsec IP VPN termination in the 
NGN to support interworking the IP VPN tunnel. 

6.2.5 Emergency calls 

In this scenario, emergency calls have to be supported entirely within the NGCN, and some other scenario provided for 
delivery to the NGN if required. 
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6.2.6 Configuration / provisioning issues 

The IP level communication between the TE CNG and the NGCN can be provided using a number of mechanisms. The 
simplest mechanism is to configure peer IP addresses or FQDNs, and appropriate credentials for the security 
mechanism in use, in the IPsec terminations IP VPN termination. The configuration of this information is outside the 
scope of the present document. 

There are no configuration requirements for supporting this scenario in the NGN. 



6.2.7 Security issues 



Security is provided by appropriate security mechanism between the IP VPN endpoints, e.g. use of IPsec or TLS. The 
NGN provides no security mechanisms. 

6.2.8 CInarging issues 

Not applicable. 

6.2.9 Transport control issues 

The TE CND interfaces to the NGN using an IPsec IP VPN termination and the CNG. 

NASS can be used, e.g. to support the allocation of a IP address to the CNG, and the authentication of the CNG as an 
endpoint. 

RACS can be used by the NGN to control enforcement of policies within the transport layer. These policies are pushed 
to the RACS by the NASS at each time the CNG attaches to the NGN. 

NOTE: The RACS could have similar functionality to the above based on receipt of the policies from the 
management plane. 

There is no support by functionality in the NASS and RACS. 



7 Scenarios relating to a level of service of session 

establishment and control of communication session 

7.1 Scenario 3: Session level virtual leased line 
7.1.1 Introduction 

This scenario describes the provision of capabilities of the NGN to support an IP multimedia virtual leased service for 
the NGCN equivalent to a leased-line scenario but between multiple NGCN sites of a single NGCN. This scenario 
involves primarily the routeing capabilities of the IM CN subsystem within the NGN. The NGCN interfaces to the NGN 
using SIP as the control protocol. The same NGCN exists at both the originating side and at the terminating side. 
Break-in and break-out traffic is not applicable with this scenario. 

As this scenario is equivalent to the leased line scenario, the routeing is fixed, i.e. a request at a specific entry point will 
always be directed to the same exit point of an NGN, the exit point maybe on the boundary between an originating and 
a terminating NGN hosting session level business communication capabilities or between a terminating NGN and a 
connected NGCN site. Scenario 6 provides a similar architecture where intelligent capabilities are supported. 
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7.1.2 



Involved functional entities - originating 



Mandatory for scenario 
Optional for scenario 




Transport 
tjirocessing functions 



to terminating side 



NOTE: One or more routeing functions can appear in the originating side for ttiis scenario. 

Figure 7.1.1 : Session level virtual leased line scenario originating functional entities 

In this particular scenario the IBCF will route based on information about the entry point, not based on the destination 
of a request. 



£75/ 



15 



ETSI TS 182 023 V2.1.1 (2009-01) 



7.1 .3 Involved functional entities - terminating 



Mandatory for scenario 



Optional for scenario 
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Transport 
processing function^ 



NOTE: One or more routeing functions can appear in the terminating side for this scenario. 

Figure 7.1.2: Session level virtual leased line scenario terminating functional entities 

In this scenario the exit point determined by the originating virtual leased line scenario is the IBCF connecting an 
NGCN site. 

7.1 .4 Interoperability with other scenarios 

The originating side session level virtual leased line scenario can interoperate with any other terminating scenario where 
the traffic relates to dialogs or transactions belonging within the enterprise network, e.g. the scenarios for hosted 
enterprise services. 

The terminating side session level virtual leased line scenario can interoperate with any other originating scenario where 
the traffic relates to dialogs or transactions belonging within the enterprise network, e.g. the scenarios for hosted 
enterprise services. 

NOTE: The functionality provided by the routeing function is that of a SIP proxy, and the functionality provided 
by the IBCF is that of a session border controller, so interoperability can be provided with existing 
solutions not based on IMS. In this case, the procedures of TS 183 021 [6] will apply at the interworking 
point. The possible functionalities of a session border controller are described in 
draft-ietf-sipping-sbc-funcs [i.2]. Such interworking may be limited by the SIP extensions that are 
supported across the interface. ES 282 001 [3] provides for an IWF which may also provide some 
appropriate functionality in this respect. The precise document to handle this capability requires further 
study. 



7.1.5 Emergency calls 



There is no direct support NGN emergency calls within this scenario, although NGCN emergency calls may be 
supported. Another scenario has to be used by the enterprise network provider to support NGN emergency calls to or 
from the enterprise network. 
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7.1 .6 Configuration / provisioning issues 

The IBCF need to be configured to route requests coming in over a specific entry point to a specific exit point. 

7.1.7 Security issues 

TS 187 003 [7] clause 13 shall apply to the interconnection between the NGCN and the NGN. 

7.1.8 CInarging issues 

Inter Operator Identifiers (lOI) shall be exchanged between the NGCN and the NGN. 
NOTE: lOI usage is not fully defined for enterprise communication in this release. 

7.1 .9 Transport control issues 

NOTE: Definition of the transport control issues in this scenario is outside the scope of this release of the present 
document. 

8 Scenarios relating to a level of service of application 

level 

8.1 General 

For each of the scenarios presented in this clause, it is possible for the NGN to provide services either at the session 
establishment and control level or at the application level, as described in clause 4.2. Some of the functional entity 
diagrams show the involvement of an AS. Where an AS is shown, this does not necessarily constitute provision of 
services at the application level, as described in clause 4.1. It is possible to deploy an AS for realizing services at the 
session establishment and control level. 

NOTE: Corporate networks can be connected in different arrangements. One is connecting them over an interface 
to a P-CSCF (subscription-based arrangement), the other is when it is connected over an interface to an 
IBCF (peering-based arrangement). 

8.2 Scenario 4: Hosted Enterprise Services (HES) 
8.2.1 Introduction 

This scenario describes the provision of capabilities of the NGN to support end users directly attached to the NGN with 
services belonging to the enterprise network. Support of both the private network routeing capabilities and services 
delivered to the end enterprise user are provided within the AS supporting the HES application. In addition to the 
existing IMS capabilities, the UPSF supports service profiles for SIP URIs with a URI parameter of user=phone and 
representing a PNP number. 
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8.2.2 Involved functional entities - originating 
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Figure 8.2.1 : HES scenario originating functional entities 

NOTE: Figure 8.2. 1 does not show the intermediate functions between the P-CSCF and the S-CSCF, or those 
between the S-CSCF and the terminating side. 

See TS 182 024 [4] for further information. 

8.2.3 Involved functional entities - terminating 
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Figure 8.2.2: IHES scenario terminating functional entities 
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NOTE: Figure 8.2.2 does not show the intermediate functions between the P-CSCF and the S-CSCF, or any 
intermediate functions before the S-CSCF from the originating side. 

See TS 182 024 [4] for further information. 

8.2.4 Interoperability with other scenarios 

The originating side HES scenario can interoperate with any other terminating scenario. A break-out function needs to 
be deployed when traffic leaves the enterprise environment and becomes public network traffic. This break-out function 
can form part of the HES application. 

The terminating side HES scenario can interoperate with any other originating scenario. A break-in function needs to be 
deployed when public network traffic enters the enterprise environment. This break-in function can form part of the 
HES application. 

8.2.5 Emergency calls 

For a UE supported in the HES environment, citizen to authority calls are normally treated as if the UE was supported 
by the NGN in the normal public subscriber manner, see TS 182 009 [1]. See TS 182 024 [4] for further information. 

NOTE: Some enterprises may require alternative arrangements, whereby emergency calls are routed to a private 
PSAP. 

8.2.6 Configuration / provisioning issues 

HES users are configured in the UPSF in the same manner as subscribers for the public NGN capabilities. The service 
profile and filter criteria relate to the provision of specialized HES by an application server. See TS 182 024 [4] for 
further information. In addition to the existing IMS capabilities, the UPSF supports service profiles for SIP URls with a 
URl parameter of user=phone and representing a PNP number. 

The IMS routeing functions (e.g. BGCF, S-CSCF, 1-CSCF) will require appropriate provisioning to route private 
network traffic, unless all calls originated from or terminated to the HES are public network traffic. 

8.2.7 Security issues 

TS 182 024 [4] shall apply to the interconnection between the NGCN UE and the NGN. 

NOTE: The present document references TS 187 003 [7] clause 14 which contains the required provisions. 

8.2.8 Charging issues 

Inter Operator Identifiers (lOI) specific to the NGCN shall be exchanged between the S-CSCF supporting the hosted 
enterprise users and the entities supporting the remote side. See TS 182 024 [4] for further information. 

NOTE: lOI usage is not fully defined for enterprise communication in this release. 



8.2.9 Transport control issues 



The NASS, RACS and transport processing functions are used in an identical fashion to a CND and CNG receiving 
NGN services. See TS 182 024 [4] for further information. 
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8.3 Scenario 5: Business trunking (subscription based) 



8.3.1 



Introduction 



This scenario describes the provision of capabilities of the NGN to support end users attached to an NGCN. In this case 
each site of the NGCN has a service subscription to the IMS, the private extensions behind the NGCN do not need their 
own service subscription, since they are owned and managed by the NGCN. The NGCN site interfaces to the NGN 
using SIP as the control protocol. 

An AS is used to provide business trunking applications, e.g. those defined in TS 181 019 [2], clause 4.4. If such 
capabilities are not required, then the AS is not included in any request processing. 

8.3.2 Involved functional entities - originating 

Figure 8.3.1 shows the functional entities involved in the originating scenario in support subscription based business 
trunking. 
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Figure 8.3.1 : Business trunlting scenario originating functional entities 

NOTE: Figure 8.3.1 does not show the intermediate functions between the P-CSCF and the S-CSCF, or those 
between the S-CSCF and the terminating side. 

See TS 182 025 [5] for further information. 
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8.3.3 Involved functional entities - terminating 

Figure 8.3.2 shows the functional entities involved in the terminating scenario in support subscription based business 
trunking. 
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Figure 8.3.2: Business trunl<ing scenario terminating functional entities 

NOTE: Figure 8.3.2 does not show the intermediate functions between the P-CSCF and the S-CSCF, or any 
intermediate functions before the S-CSCF from the originating side. 

See TS 182 025 [5] for further information. 

8.3.4 Interoperability with other scenarios 

The originating side business trunking scenario can interoperate with any other terminating scenario. A break-out 
function needs to be deployed when traffic leaves the enterprise environment and becomes public network traffic. 

The terminating side business trunking scenario can interoperate with any other originating scenario. A break-in 
function needs to be deployed when public network traffic enters the enterprise environment. 

8.3.5 Emergency calls 

For an NGCN site that has a subscription to the IMS, emergency calls ingressing to the NGN are normally treated as if 
the NGCN was supported by the NGN in the normal pubHc subscriber manner, see TS 182 009 [1]. See TS 182 025 [5] 
for further information. 

NOTE: Some enterprises may require alternative arrangements, whereby emergency calls are routed to a private 
PSAP. 
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8.3.6 Configuration / provisioning issues 

NGCN sites are configured in the HSS in the same manner as subscribers for the public NGN capabiUties. The service 
profile and filter criteria relate to the provision of specialized enterprise services by the business trunking application; it 
is these services that are supported on an AS. See TS 182 025 [5] for further information. 

The IMS routeing functions (e.g. BGCF, S-CSCF, I-CSCF) will require appropriate provisioning to route private 
network traffic, unless all calls originated from or terminated to the business trunking are public network traffic. 

8.3.7 Security issues 

TS 182 025 [5] shall apply to the interconnection between the NGCN UE and the NGN. 

NOTE: The present document references TS 187 003 [7], clause 13 which contains the required provisions. 

8.3.8 CInarging issues 

Inter Operator Identifiers (lOI) specific to the enterprise subscription for the NGCN shall be exchanged between the 
S-CSCF serving the NGCN site and the entities supporting the remote side. See TS 182 025 [5] for further information. 

NOTE: lOI usage is not fully defined for enterprise communication in this release. 

8.3.9 Transport control issues 

The NGCN site interfaces to the NGN using the CNG which can be an integral part of the NGCN equipment. 

The media requirements identified by the control protocol use the transport processing functions, and may be supported 
by functionality in the NASS and RACS. 

Static IP address assignment is valid and does not need NASS. MACE provides DHCP server dynamic address which is 
part of NASS. UAF is for authentication. 

8.4 Scenario 6: Business trunking (peering based) 
8.4.1 Introduction 

This scenario describes the provision of capabilities of the NGN to support end users attached to an NGCN. In this case 
the NGCN operator has a service level agreement with the IMS operator. Services are provided to the private extensions 
behind the NGCN using the NGCN. The NGCN sites interface to the NGN using SIP as the control protocol. 

Intelligent routeing tables at the routeing function are used to provided business trunking applications, e.g. those defined 
in TS 181 019 [2], clause 4.4. If such capabilities are not required, then the AS is not included in any request 
processing. 



£75/ 



22 



ETSI TS 182 023 V2.1.1 (2009-01) 



8.4.2 Involved functional entities - originating 

Figure 8.4.1 shows the functional entities involved in the originating scenario in support of peering-based business 
trunking. 
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NOTE: One or more routeing functional entities can appear in ttie originating side for tliis scenario. 
Figure 8.4.1 : Business trunlting scenario originating functional entities 

NOTE: The precise functionality of the intelligent routeing tables requires further study (see also clause 6.2.6 of 
TS 182 025 [5]). 

See TS 182 025 [5] for further information. 
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8.4.3 Involved functional entities - terminating 

Figure 8.4.2 shows the functional entities involved in the terminating scenario in support of peering-based business 
trunking. 
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NOTE 1 : One or more routeing functional entities can appear in the originating side for \h\s scenario. 
Figure 8.4.2: Business trunlting scenario terminating functional entities 

NOTE 2: The precise functionality of the intelligent routeing tables requires further study (see also clause 6.2.6 of 
TS 182 025 [5]). 

See TS 182 025 [5] for further information. 

8.4.4 Interoperability with other scenarios 

The originating side business trunking scenario can interoperate with any other terminating scenario. A break-out 
function needs to be deployed when traffic leaves the enterprise environment and becomes public network traffic. 

The terminating side business trunking scenario can interoperate with any other originating scenario. A break-in 
function needs to be deployed when public network traffic enters the enterprise environment. 

NOTE: The functionality provided by the routeing function is that of a SIP proxy, and the functionality provided 
by the IBCF is that of a session border controller, so interoperability can be provided with existing 
solutions not based on IMS. In this case, the procedures of TS 183 021 [6] will apply at the interworking 
point. The possible functionalities of a session border controller are described in draft-ietf-sipping-sbc- 
funcs [i.2]. Such interworking may be limited by the SIP extensions that are supported across the 
interface. ES 282 001 [3] provides for an IWF which may also provide some appropriate functionality in 
this respect. The precise document to handle this capability requires further study. 
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8.4.5 Emergency calls 



None of the functional entities in this scenario have any functionality specific to the recognition of emergency calls or 
to the substitution of the Request-URI when such a call exists. Identification of emergency calls is therefore expected to 
be performed in the NGCN. However, the routeing tables are expected to be configured to route private network traffic 
in a manner different to public network traffic. Delivering emergency calls is integral to that routeing configuration. 

NOTE: Some enterprises may require alternative arrangements, whereby emergency calls are routed to a private 
PSAP. 



8.4.6 Configuration / provisioning issues 



NGCN sites are configured in the same manner as service level agreements with other public network operators. See 
TS 182 025 [5] for further information. 

The IMS routeing functions will require appropriate provisioning to route private network traffic, and to provide the 
business trunking applications, unless all calls originated from or terminated to the business trunking are public network 
traffic. 

8.4.7 Security issues 

TS 182 025 [5] shall apply to the interconnection between the NGCN UE and the NGN. 

NOTE: The present document references TS 187 003 [7], clause 13 which contains the required provisions. 

8.4.8 Charging issues 

Inter Operator Identifiers (lOI) shall be exchanged between the NGCN and the NGN. 
NOTE: lOI usage is not fully defined for enterprise communication in this release. 



8.4.9 Transport control issues 



NOTE: Definition of the transport control issues in this scenario is outside the scope of this release of the present 
document. 



9 Scenarios relating to roaming 

9.1 Scenario 7: NGCN user roaming into NGN public network 
9.1.1 Introduction 

This scenario describes the provision of capabilities of the NGN to support end users whose home location is an NGCN 
roaming into an NGN. 
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9.1 .2 Involved functional entities 



Mandatory for scenario 



Optional for scenario 



Gm 



NGCN 
UE 



Visited IMS 



P-CSCF 



82 



I MASS 

I 



IVlx 



IBCF 



Gq' 



I RACS 



Gq' 

"I 
I 
I 
I 



Tra isport 
ijirocessing functions 



Home NGCN 



CNG 



NGCN 



Figure 9.1.1 : NGCN user registering from visited NGN withi whiichi NGCN hias a roaming agreement 
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Figure 9.1.2: NGCN user registering from visited NGN via NGN with) whiichi both) visited NGN and 

NGCN hiave a roaming agreement 

NOTE: Functional entities in NGN with which the NGCN has a roaming agreement support either 
peering-based or subscription-based approach for business trunking. 
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A registration request submitted by an NGCN UE attached to a NGN is routed into the NGCN, either to the NGCN site 
directly when there exists a roaming agreement between the NGN and the NGCN; or indirectly via an NGN that has a 
roaming agreement with the NGCN which then transits the traffic to the home NGCN where the registrar is located. 
IBCF or equivalent functionality may exist at the network borders. 

Other requests (e.g. for call establishment) are routed similarly to the proxy in the NGCN home site. Requests to the 
NGCN UE are sent in the opposite direction. 

See TS 182 025 [5] for further information. 

9.1.3 Void 

9.1 .4 Interoperability with other scenarios 

The Roaming NGCN User scenario can interoperate with any originating scenario and any terminating scenario. 
Specifically, a roaming NGCN user can: 

• originate a call in which the user's home NGCN is the originating side of the NGCN transit scenario; 

• originate a call in which the user's home NGCN is the originating side of a business trunking scenario 
(subscription-based or peering-based); 

• terminate a call in which the user's home NGCN is the terminating side of the NGCN transit scenario; 

• terminate a call in which the user's home NGCN is the terminating side of a business trunking scenario 
(subscription-based or peering-based). 

9.1.5 Emergency calls 

NOTE: Not addressed in this release of the document. 

9.1 .6 Configuration / provisioning issues 

NOTE: Not addressed in this release of the document. 

9.1.7 Security issues 

NOTE: Not addressed in this release of the document. 

9.1.8 Charging issues 

NOTE: Not addressed in this release of the document. 

9.1 .9 Transport control issues 

NOTE: Definition of the transport control issues in this scenario is outside the scope of this release of the present 
document. 

9.2 Scenario 8: NGCN user roaming into another NGCN site of 
the same enterprise 

9.2.1 Introduction 

This scenario describes the provision of capabilities of the NGN to support end users whose home location is an NGCN 
site roaming into another NGCN site of the same enterprise. This scenario is not supported in the current release. 
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9.3 Scenario 9: HES user roams into NGCN site of the same 
enterprise 

9.3.1 Introduction 

This scenario describes the provision of capabiHties of the NGN to support HES users whose home location is an NGN 
roaming into an NGCN site of the same enterprise. This scenario is not supported in the current release. 

9.4 Scenario 10: HES user roams into anotiner NGN 
9.4.1 Introduction 

This scenario utilizes existing NGN roaming capabilities. 

9.5 Scenario 1 1 : NGN public network user roaming into NGCN 
9.5.1 Introduction 

This scenario describes the provision of capabilities of the NGN to support end users whose home location is an NGN 
roaming into an NGCN. This scenario is not supported in the current release. 

9.6 Scenario 12: NGCN user roaming into an NGCN of a 
different enterprise 

9.6.1 Introduction 

This scenario describes the provision of capabilities of the NGN to support end users whose home location is an NGCN 
roaming into another NGCN belonging to a different enterprise. This scenario is not supported in the current release. 
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